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[57] ABSTRACT 

An Object-Action Manager shields an applications de- 
veloper from multiple display technologies and devel- 
opment tools and assists the developer in applications 
user interface creation. The manager includes a parser, 
an object-list builder, dialog-box builder, a library of 
access functions and a display handler. The object-list 
builder and dialog-box builder are used to build user 
interface screen definitions according to predetermined 
parameters. The parser reads a developer-defined de- 
scription File and builds data structures. The object-list 
builder and dialog-box builder use the data structures to 
customize the user interface screens for the developer. 
The library contains functions used during operation of 
the user interface. The display handler manages interac- 
tion between the end-user and the developed applica- 
tion. 

15 Claims, 8 Drawing Sheets 
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before the user interface can be initially viewed or sub- 

OBJECT-ACTION USER INTERFACE sequently modified. Because user interface develop- 

MANAGEMENT SYSTEM m ent is highly iterative, rapid prototyping is essential to 

effective development. Yet many general-purpose user 

BACKGROUND OF THE INVENTION 5 interface tools fail to facilitate rapid initial development 

1. Field of the Invention of partially functioning prototypes. Furthermore, these 
The present invention relates generally to software tools l a ck the ability to quickly apply changes to an 

development tools and more particularly to a high- existing prototype. Without quick feedback, the devel - 

Ievel, application-class specific user interface develop- oper is at a disadvantage during the development cycle, 

ment tool. 1° The aforementioned disadvantages and limitations 

2. Description of the Prior Art retard application development and place the usability 
User interface tools assist software application devel- of the application at serious risk, particularly for large 

opers in the design and development of computer appli- interactive applications. It would be a great benefit if a 

cations software. There are two groups that interact development tool could be designed to handle the hun- 

with computer applications software. The first group, 15 dreds of functions and myriad style options involved in 

noted above, are application developers. This group is interface development, while allowing the systems de- 

responsible for creating the software according to de- veloper more time to concentrate on perfecting the 

sign specifications which may be driven by the develop- interface consistency and overall performance, 
ers themselves, or the second group— the application 

software end-users. The relationship between the two 20 SUMMARY OF THE INVENTION 

f i S d> ? amic in that each contribute in P ut anc * The present invention overcomes the disadvantages 

feedback to the other. and limitations of the prior art by providing a high- 

Typically these tools are general-purpose. That is, level) user interface deve lopment tool. In particular, an 

the tools enable the development of a very broad range object-Action Manager shields an applications devel- 

of user interface styles. One disadvantage is that these 25 frQm | technologies and develop- 

tools often contain hundreds of functions in order to be Jl nt rt „ A I i • r 

general-purpose. The developer must acquire a working ^ °° 1S ^ h ^ lo P er In applications user 

knowledge of most of these functions to use the tool " * C C ^ ° ™? ^neral-purpose, the 

This leaves the developer in the unenviable position of ?^ t f ' * apP ^T^ $P ? 

first learning the intricacies of the tool, which can take 30 ™ at is, the user interface created by the Object-Action 

weeks or months, before any development can begin. Manager allows a user to manage lists of objects, input 

A second disadvantage of the general-purpose user ™ d m( ? dlfy P arameter * for performing tasks, and step 

interface tool, stemming again from the generality, is through complex procedures. 

that the tool does not constrain the developer to use the . The Object-Action Manager controls the many user 
tool in a way that yields consistent appearance and 35 in *erface features which are typically in the hands of 
behavior among the common elements of the applica- several developers. These features include: (1) the inter- 
tion's user interface. Achieving consistency and avoid- actl0n P ara digm; (2) selection and navigation methods; 
ing arbitrary differences among common elements thus positioning and labeling of common elements; (4) 
becomes an arduous task of writing and revising style relative screen layout; (5) error handling; and (6) dis- 
guides and manually reviewing all parts of the user 40 P Iav technology-specific factors such as fonts and cur- 
interface to ensure conformance with the style guide. sor shapes. This control, provided by the Object- Action 
However, style guides are inherently difficult to en- Manager, facilitates learning and overall user interface 
force since the guide is a mere suggestion. There is no consistency. 

mechanism to impose a particular style upon the devel- Generally, the Object- Action Manager comprises a 

oper. Further, ensuring user interface consistency is 45 description file interpreter and a library of access func- 

particularly challenging given the myriad options avail- tions. The description file interpreter effects the system 

able to the developer in today's user interface tools. start-up procedure. In addition, the interpreter reads 

These disadvantages are compounded if the applica- data files that define the screens to be used in the user 

tion being developed is large enough to require the interface. These files define the type of objects to be 

efforts of multiple developers. The developers, who 50 managed, the attributes of those objects, the available 

often are not user interface designers and may be lo- actions which can be taken on. those objects and the 

cated at geographically remote locations, must scale the necessary inputs to effect those actions. An advantage 

steep learning curve of the general-purpose user inter- of this description file interpreter is the resulting consis- 

face tool. Each developer arrives at a unique under- tency among the application screens that are built and 

standing of how to achieve the desired standard style 55 displayed to the end user. By shielding the developer 

with the numerous graphic and display elements which, from the underlying system and display technology 

in various combinations, define a given user interface through the use of a high-level description language, 

application. Further, the developers, each having a the interpreter decreases the chance for screen inconsis- 

unique approach to standardizing the application's tencies typically introduced in conventional develop- 

style, must coordinate all design and implementation 60 ment tools. 

decisions in an attempt to avoid arbitrary inconsisten- The library of access functions supplies the developer 
cies in the user interface. Thus, development of large with routines for accessing the screens defined in the 
applications with multiple developers requires added description file, for example. By invoking these rou- 
care since this situation is inherently disposed to appli- tines, the developer can read and manipulate user inter- 
cation inconsistencies. 65 face screens. In particular, a value can be read from, or 
Several general-purpose user interface tools have placed into, a designated field on the screen. Other 
lengthy development cycles consisting of repeated edit- routines allow the developer to display error messages, 
ing, recompilation, and re-linking of the application for example, upon the occurrence of an event. 
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BRIEF DESCRIPTION OF THE DRAWINGS 

FIG. 1 shows an overview of the Object-Action 
Manager according to the present invention. 

FIG. 2 shows a more detailed illustration of the Ob- 5 
ject-Action Manager. 

FIG. 3 shows the functional flow diagram of the 
object-action paradigm according to the present inven- 
tion. 

FIG. 4 shows an object-list screen map according to 10 
the present invention. 

FIG. 5 shows a task dialog screen map according to 
the present invention. 

FIG. 6 shows an example of a task dialog screen. 

FIG. 7 shows an example of a task dialog screen 15 
having an add-on selector. 

FIG. 8 shows a step menu screen map according to 
the present invention. 

DETAILED DESCRIPTION OF THE 2Q 
PREFERRED EMBODIMENT 

The present invention provides high-level, user inter- 
face development tool for developers of system admin- 
istration tools and similar object management applica- 
tions such as data base access. 25 

As used herein, the following terms and phrases are 
defined as follows: 
access function: 
a subroutine supplied by the Object-Action Manager 
for the application developer's use in callback func- 30 
tions; access functions retrieve data from the 
screens, place data in the screens, or otherwise 
manipulate the user interface, 
add-on list: 

a complex selector typically consisting of a label, a 35 
scrollable list, an input region, and a set of push 
buttons allowing list items to be added, removed, 
or modified by the user, 
application: 

a computer software program; applications discussed 40 
herein are additionally interactive applications: 
they have a user interface, 
attribute: 

a characteristic of an object, e.g., a printer object has 
"name" as an attribute; also, selectors have attri- 45 
butes that the developer can specify to affect the 
behavior or appearance of the selector. 

callback function: 
a subroutine written in a programming language (e.g., 
the C programming language), which is invoked by 50 
the user interface management system when a cer- 
tain related user action occurs. For example when 
the user presses the "OK" pushbutton in a task 
dialog, the "OK callback" function is invoked. 
Callback functions are supplied by the developer 55 
where they are needed. 

character-based terminal: 
a computer display device where the basic element of 
construction is a character (letter, number, symbol, 
etc.) and where a keyboard is typically .the only 60 
input device. 

control buttons: 
a set of buttons at the bottom of a dialog box; buttons 
are used for performing a task, dismissing the dia- 
log box, or requesting help. 65 

description file: 
a text file containing the user-interface screen defini- 
tions; these definitions use a simple syntax. 



4 

developer: 

the person who creates an application 
dialog box: 

a screen allowing data entry or data viewing, with a 
set of control buttons at the bottom; types of dialog 
boxes in Object-Action Manager include task dia- 
logs, step menus, message boxes, and view menu 
dialogs. 

graphical user interface: 
a user interface where the fundamental element of 
construction is the pixel (a dot of color) and where 
devices typically include a pointing device such as 
a mouse or trackball in addition to a keyboard; 
typically, graphical user interfaces make use of 
screens, dialog boxes, push buttons, menubars, and 
the like. 

interaction paradigm: 
a model of how a user interacts with an application, 
e.g., the object-action paradigm. In the object- 
action paradigm the user first selects an object and 
then picks an action to perform on the selected 
object. 

menu: 

a list of words or phrases, from which one (at a time) 
may be selected by the user to accomplish some 
application action, 
menubar: 

an area at the top of a screen containing words which, 
if selected, display a list of choices (pull-down 
menu) from which the user may pick; menubars 
provide hierarchical menu systems, 
message box: 

dialog box containing only a message and an appro- 
priate set of control buttons, 
object: 

a data item, typically with multiple attributes. 
Object-Action Manager: 

a high-level, application-class- specific user-interface 
development tool, 
object-list: 

a textual display of the attribute values of a data item; 
items in an object list can be selected, filtered, 
sorted, or otherwise rearranged by the user. 

object-list screen: 
an object-list screen allows a user to view a list of 
objects, select objects, and perform actions (via an 
"Actions'* menu), which may or may not affect the 
selected objects, usually contains a screen with a 
menubar, a status area, and an object-list. 

option menu: 

a labeled button selector which, when activated, dis- 
plays a menu of choices; the selected choice re- 
places the label on the button, indicating the cur- 
rent choice, 
push button: 

a word or phrase with the appearance of a button, 
which, when activated by the user, accomplishes 
some user interface operation. 

radio buttons: 
a type of non-scrolling, mutually-exclusive selection 
list, where when the user picks one option (by 
pressing a button to the left of a label), the other 
options are automatically deselected, thus allowing 
only a single selection at a time from a limited 
number of choices. 

screen: 

a bounded display of user interface information and 
controls; graphical user interfaces typically allow 
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screens to be moved, re-sized, or otherwise manip- screens within a description file 210. Programming 
ulated by the user. routines, located in an application code 220 file, are also 

selection list: created by the developer for manipulating the interface 

a selector allowing single or multiple selection of screens. The description file 210 and the application 
items from a small or large number of choices. This 5 code 220 are both created using the high-level applica- 
can be represented as a group of toggles, a set of tion programming interface (API) provided by the Ob- 
radio buttons, an option menu, or a scrolling list- ject- Action Manager 110. This high-level API, which 
box, depending on the selection policy, the number has a simple definition syntax (see Appendix A), facili- 
of items, and the available screen space. tales user interface application development. The defi- 

selector: 10 nition syntax is less complex than the syntax provided 

an element of the task area of a task dialog that allows by general-purpose user interface management systems, 
the user to input data or view information. Exam- Maintaining this high-level API between the applica- 
ples of selectors are: text edit, static text, push but- tions developer and the Object- Action Manager 110 is 
ton, add-on list, selection list, toggle, read-only list. critical to the success of the invention, 
static text: 15 The description file 210 contains the user interface 

a textual, non-scrolling selector which cannot be screen definitions. A feature of the Object-Action Man- 
manipulated by the user. ager 110 is the user interface paradigm supported. This 
step menu: interface (which is described in more detail with respect 
a dialog box providing a control for each step of a to FIGS. 4-8) comprises three components: (1) the 
complex procedure and adjacent status areas for 20 object-list; (2) the task dialog; and (3) the step menu, 
keeping the user appraised of his/her progress. Briefly, the user manages objects, which are designated 
subarea: by the applications developer in the description file 210, 
a set of definitions which include a type of object, the through the object-list interface. The task dialog inter- 
object's attributes, the actions that can be per- face processes parameter inputs entered by the user for 
formed on that object. 25 specified actions and functional steps. The step menu 
task dialog: interface screen provides a controlled manner for per- 
a dialog box, specified by the developer, which al- forming complex procedures. 

lows the user to input task parameters or view task The developer also specifies the following types of 
information; usually contains a task area and con- information (not an exhaustive list) while defining the 
trol buttons. 30 three screen types: element identifiers (required) — these 

text edit: identifiers can be used in application code to refer to the 

an editable text selector with an adjacent label. screen elements and can also be used within the descrip- 

toggle: tion files as variables, callback names (optional) — these 

a selector which the user can set on or off, indepen- can be used where needed, default values (optional), 
dent of the settings of other toggles. A toggle is 35 help identifiers (optional), element size (optional) — the 
typically represented as a button to the left of an object-list manager provides a default size, 
associated label. In addition to the description file 210, the developer 

user: creates application code 220 specific to the user inter- 

the person who uses the application the developer face application. Another feature of the Object- Action 
creates. 40 Manager 110 is the ease in which the application code 

user interface: 220 can be created. The developer can take advantage 

that part of an application which the end user inter- of access functions located in the user interface library 
acts with in order to use the application. (Uilib) 240 by including these functions when creating 

FIG. 1 shows a system overview. The applications the application code 220. Since Uilib 240 contains many 
developer interacts with the object-action management 45 access functions such as selector routines and message 
system 110, which in turn accesses and manipulates the routines, overall application development time is de- 
general purpose user interface manager 120, which is creased. More specifically, the Uilib 240 provides func- 
embedded in the object-action management system 110. tions that read data from screens, put data on screens, 
In a preferred embodiment, the general purpose user invoke new screens, or otherwise manipulate the user 
interface manager 120 is Dialog Manager on an OSF- 50 interface. Uilib 240 also provides a simple means of 
/Motif software platform. Dialog Manager is available displaying messages, including (but not limited to) con- 
from Informationssysteme fur computer-integrierte Au- firmation, information, error and progress status mes- 
tomatisierung GmbH (ISA), Stuttgart, Germany. OSF- sages. Once the developer decides what objects can be 
/Motif is available from Open Software Foundation, displayed and selected by the user in the description file 
Inc., 11 Cambridge Center, Cambridge, Mass., 02142. 55 210, any object manipulations or other functions are 
Other general purpose interfaces such as the X Win- defined within the application code 220. For example, 
dows System may be used, with slight modifications to the developer may specify a group of users as the object 
the Object-Action Manager 110, without departing which will be displayed and selected. The description 
from the spirit and scope of the invention. The object- file 210 contains the necessary information to define the 
action management system 110 shields the developer 60 group (for example, names, attributes), while the appli- 
from the intricacies of the general purpose user inter- cation code 220 contains the necessary functions to 
face manager 120 thereby reducing the learning curve manipulate the group, such as setting user privileges, 
and reducing the chance for interface discrepancies. The parser 230 contains the start-up procedure for 
This facilitates rapid development of prototypes and the Object-Action Manager 110. In addition to initial- 
application-specific user interfaces. 65 izing the system, the parser 230 accesses and interprets 
FIG. 2 shows the functional control flow of the Ob- the description file 210, creating data structures which 
ject- Action Manager 110. The applications developer are used by the object-list executor (OLE) 250 and the 
creates a user interface application by defining interface dialog box builder (DiBB) 260 to build user interface 
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screens. An important feature of the Object-Action Action Manager will display an error message. The user 

Manager 110 is the late binding convention employed will then enter a new action. If a parameter is needed to 

by the parser 230. Instead of creating data structures effect the action 336, the Object-Action Manager will 

through a compilation or similar step, all data structure invoke a dialog task interface screen which will wait for 

creation is performed at run-time. This decreases proto- 5 the user to enter the required parameter 338. Finally, 

typing time by provtding the developer with immediate the action, with the proper parameters), will be per- 

feedback upon initializing the interface. Additionally, formed 340. 

late binding facilitates iterative development of the FIG. 4 shows an object-list screen map. While it is 
interface because changes are quickly applied to the not required, the object-list screen 400 can be the first 
prototype. The net effect of the late binding convention 10 screen displayed when the Object-Action Manager is 
is decreased development time for the application. initialized. Generally, the object-list screen 400 pro- 
Interface screens are built and maintained by the vides list manipulation capabilities and comprises a title- 
object-list executor (OLE) 250 and the dialog box bar 410, a menubar 420, a status area 430, a column 
builder (DiBB) 260. The OLE 250 creates object-list labeling area 440, an object-list region 460, and scroll 
screens (see FIG. 4) according to the description file 15 bars 450, 452. 

210. Additionally, the OLE 250 processes events gener- The object-list region 460 displays the objects being 

ated by the user at the display handler 270. Among the managed. If the objects being displayed require a region 

structures included in an object-list screen are an Action larger than a default region size, scroll bars 450, 452 

menu containing a list of actions to perform on selected allow the user to see the entire list by scrolling either 

objects, and a View menu through which the user can 20 vertically or horizontally. Typically, each object will 

customize the display of objects on the object-list have a set of attributes which may, or may not, be dis- 

screen. played initially with the associated object. An applica- 

The DiBB 260 is responsible for building task dialog tions developer may define private attributes that are 
and step menu screens and processing associated events. not visible or accessible to the end user. Those attributes 
Data structures created by the parser 230 are used by 25 displayed will have appropriate headings. The applica- 
tive DiBB 260 to build task dialog screens and step menu tions developer initially decides, within the description 
screens (see FIG. 5 and 8, respectively). The developer file, what attributes to display. The user, applying a 
can modify values in the DiBB data structures, and thus variety of options in a View menu located on the menu- 
affect application behavior, through the use of access bar 420, can then alter the display by suppressing some 
functions in the Uilib 240. 30 attributes, for example. 

The Object- Action Manager 110 will begin with The menubar 420 is unique to the object-list screen 

whatever screen is defined first in the description file 400 (that is, task dialog and step menu interfaces have 

210. For example, if an object-list screen interface is the no menubar) and provides control for object manipula- 

first defined, the OLE 250 is invoked upon initialization tion. The menubar 420 comprises a List menu, a View 

of the application to build the object-list interface. Sub- 35 menu, an Action menu, an Options menu and a Help 

sequently, the DiBB 260 is invoked only when an inter- menu. The List menu provides control over a subarea, 

face screen other than an object-list screen is actually or list of objects and its associated actions. In a pre- 

needed, not when the parser 230 interprets the descrip- ferred embodiment, the menubar 420 may also include a 

tion file 210. This scenario is in accordance with the late Scope item which facilitates management of multiple 

binding convention discussed above. Furthermore, this 40 computer systems simultaneously. The Scope item ac- 

scenario can be altered so that a dialog screen interface cepts multiple system names that when an action is 

is the first screen to be displayed upon initialization of subsequently performed, that action will apply to the 

the application. designated computers equally. 

The display handler 270 manages communications A feature of the Object-Action Manager is the View 

between the host computer display 280 and the Object- 45 menu. The user can customize the object-list region 460 

Action Manager 110, and more particularly, Uilib 240, through this interface item. That is, the View menu has 

the OLE 250 and the DiBB 260. In a preferred embodi- options that, when selected by the user, manipulate the 

ment, the host computer is an HP 9000 computer avail- object list by filtering out any number of objects, sorting 

able from Hewlett-Packard Company, a California cor- the objects, or arranging the columns. Each of these 

poration having a place of business at 3000 Hanover 50 view items has an associated dialog screen, provided by 

Street, Palo Alto, Calif. 94304. Some possible examples the Object-Action Manager, which controls the user's 

of a display 280 include (1) a character-based terminal; manipulations. A filter dialog screen allows the user to 

(2) a workstation graphics display; and (3) a PC graph- view a subset of the object-list based on a selected attri- 

ics display. Indeed, any display technology can be em- bute value such as listing printers that are active. A 

ployed as the display 280 and in each instance, the dis- 55 columns dialog is provided to re-format the object list 

play handler 270 accommodates any platform-specific columns with respect to the object attributes. A sort 

protocol. dialog sorts the object list based on user-prioritized 

FIG. 3 shows a flow diagram of the object-action attributes in either an ascending or descending manner, 

paradigm employed by the Object-Action Manager. Additionally, the user has the option to save a changed 

Where an object-list screen is defined first in the de- 60 view as a default view so that upon re-initialization of 

scription file, the user is required to select which func- the Object-Action Manager, the saved view will be 

tional area 310 to display before any object manipula- recalled. Since the View menu is provided by the Ob- 

tion can take place. The functional area, or subarea, will ject-Action Manager, there is no programming required 

contain a list of objects and associated attributes. The from the applications developer to effect this feature, 

user may then select an object 320 from the displayed 65 The Actions menu of menubar 420 contains actions 

functional area. Once this object is selected, the user which can be common to all subareas or specific to a 

may then select an action 330 to be performed upon the designated subarea. A subarea defines a set of objects 

selected object. If the action is not valid, the Object- and actions associated with those objects. Each subarea 
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defined will appear on the List menu. An action may be object-list screen (see FIG. 4) and the action selected 

either performed directly upon a selected object, or a requires parameters to be specified or approved, 

group of selected objects, or the action may require A task dialog screen 500 may be nested within an- 

confirmation or parameters before the action is exe- other task dialog screen. In this instance, a task dialog 

cuted. Where intermediate user interaction is required, 5 screen 500 is invoked when -the-user-selects an option 

"to provide action confirmation for example, a task dia- within an already displayed task dialog screen and this 

log screen interface will be called by the action to ac- selected option requires parameter input. Still further, a 

cept such confirmation. When an action is not needed, task dialog screen 500 can be called from a step menu 

the Object-Action Manager will dim the specific action screen (see FIG. 8). 

on the Action menu so that the user cannot select it 10 A task dialog screen 500 comprises a titlebar 510, the 

(e.g., the remove action when no objects are currently task region 520 and a control area 530. The titlebar 510 

selected). indicates what task has been invoked; it provides confir- 

As mentioned above, a subarea defines a set of objects mation that the user selected the proper task from a 

and associated actions. The applications developer can previous area. The control area 530 contains various 

define a plurality of subareas for the object-list screen 15 control buttons, including closing the dialog screen 500, 

400. Each subarea has a label attribute which defines the performing specified tasks, and accessing an on-line 

text string that will appear in the List menu and is also help facility. 

used by the Object-Action Manager to indicate, in the There are four types of task dialogs: (1) read-only; (2) 

status area 430, which list is currently displayed on the standard; (3) repeatable; and (4) default-ok. Read-only 

object-list screen 400. A subarea callback initializes the 20 task dialogs are for the display of information only, 

object list region 460 with subarea objects, the status That is, no real "task" or modification is performed and, 

area 430 with the appropriate labeling, and the Actions consequently, the control area 530 typically has one 

menu in the menubar 420 with subarea-specific actions. control button to close the dialog and a second control 

The object list region 460 can also be initialized by a button for invoking help. Where the user does not want 

command. 25 or need to repeat a specified task, a standard task dialog 

Another feature of the object-list screen 400 subareas screen 500 is displayed. The control area 530 of this 

is the subarea table definition. The applications devel- screen allows the user to perform the task or cancel; the 

oper provides each subarea with a table definition. The screen is closed upon either action. A repeatable task 

table definition consolidates all the relevant information dialog screen 500 is displayed where the user may need 

needed by the ObjectAction Manager to display a set of 30 to perform a task multiple times. In this instance, the 

objects with associated attributes. control area 530 comprises a control button which will 

For example, an application for managing printers allow the user to perform the task without closing the 

could contain two subareas, one for printers and one for dialog. The user can enter a parameter and press the 

print requests. For the printers subarea, the object attri- return key to perform the task through a default-ok task 

butes can be request name, status, type and location. 35 dialog. While the control area 530 of this screen con- 

The actions for this subarea could be "add local tains cancel, help and OK buttons, the OK button need 

printer," "add remote printer," "add network printer" not be pressed. The task is performed and the task dia- 

and "start up/shut down print spool.". For the print log screen 500 is closed when the user presses the return 

requests subarea, the object attributes can be request key, which automatically "presses" the OK button. This 

identification, owner, priority, file and size. The associ- 40 obviates the need for additional user interaction, such as 

ated actions could be "cancel request" and "start up/- pressing a "close" or j"OK" button, 

shut down print spool." The "start up/shut down print As mentioned above, the task region 520 of the task 

spool" would be common to both subareas. dialog screen 500 is very flexible. The Object-Action 

The object-list screen 400 also accommodates a hier- Manager accommodates a variety of task dialogs. These 

archical list of objects. Objects displayed on the initial 45 tasks are characterized by selectors which are used to 

object-list screen 400 actually represent lists of objects. construct the task dialog screen 500, and more particu- 

Once an object from this initial list is selected and larly, the task region 520. A selector can.be a user inter- 

"opened," the hierarchical list within this selected ob- face element which accepts task parameter inputs from 

ject replaces the initial list of objects displayed on the the user, for example. These selectors provide the 

screen 400. Hierarchical lists can either be homogene- 50 means for interacting with the application. Other selec- 

ous or heterogeneous with respect to the object's attri- tors are information-only in nature. The task dialog 

butes and the associated actions. Homogeneous hierar- screen 500 must have at least one selector to be built, 

chies have no effect on the Actions menu or the col- In addition to the selectors used to construct a task 

umns displayed. Heterogeneous hierarchies may have dialog screen 500, the Object-Action Manager provides 

different Action menu items at each level of the hierar- 55 layout constructs. These constructs, accessible by the 

chy. Additionally, the columns specifications are unique applications developer, provide custom control over 

to each level since the list differs with respect to the the task dialog screen's layout An important feature of 

attributes. The Object-Action Manager tracks the navi- these layout constructs is the high-level control pro- 

gation of the hierarchical list and provides a field which vided to the applications developer. For example, a 

indicates what level the user is currently viewing as 60 skip—line construct is provided to add blank lines to the 

well as where the user has traversed. task dialog screen by simply invoking the construct; 

A task region dominates the task dialog screen shown there is no need to count pixels to effect screen layout, 

in FIG. 5. This task region 520 accommodates a wide If no layout constructs are used, the Dialog Box Builder 

variety of selectors as will be discussed more fully be- lays out the selectors sequentially without overlaps, top 

low. The task dialog screen 500 is usually invoked when 65 to bottom. 

the application, calls for additional input from the user. In this example, the Object-Action Manager uses 

In particular, the task dialog screen 500 appears when seven selectors: (1) static text; (2) text edit; (3) toggle; 

the user selects an action from the Actions menu on the (4) push button; (5) read-only list; (6) selection list; and 
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(7) an add-on list selector. However, this list is not ex- cannot be modified. This selector is particularly useful 
haustive. The task dialog screen 500 can be built with where the user may want a list of users who are cur- 
other selectors which are well known in the art (for rently logged onto a system, for example, 
example, a slider selector) or those selectors yet to be The selection list selector 660 allows the user to select 
discovered. A feature of the object action manager is 5 one or more items from a list. A feature of the selection 
that the selectors have been designed to have an op- list selector 660 is the various representations that may 
tional attribute. If the application developer flags a be used in displaying the selection list such as toggles, 
selector as optional, then the user does not have to radio-buttons, option-buttons and a list box. The Ob- 
supply a value for the task to proceed. The task can only ject-Action Manager will automatically choose which 
proceed after each input to the selectors is validated. 10 representation will be used based on the selection list 

FIG. 6 shows an example of a task dialog screen selector 660 definition. For example, where the number 
interface 600. A static text selector 610 defines text in a of items is static, there are 6 or fewer choices, and only 
task dialog which is not accessible by the user. This text one item may be selected at a time, the Object- Action 
is typically informational in nature and can be instruc- Manager will use the radio-buttons representation for 
tional comments, for example. The length of the text 15 this particular selector. However, the applications de- 
string is defined by the length of the actual text within veloper has the ability to override this default scheme 
the description file. The contents of the static text selec- by explicitly defining the representation within the se- 
tor 610 may be changed via a Uilib function. lection list selector 660 definition. 

A text edit selector 620 provides an editable field In FIG. 7, a second example of a task dialog screen 

which accepts inputs from the user. This selector 620 is 20 interface 700 is shown. A feature of the task dialog 

used where the application requires textual input from interface is the add-on list selector 710 which provides 

the user, for example. The text edit selector 620 com- the user mechanism to manipulate a list of objects 

prises several attributes including a label field 622, a within the task dialog interface. The user may add items 

help attribute (not shown) and an input field 624 and to the list, remove items from the list or modify items on 

associated specifications. The label field 622 may be 25 the list by selecting the appropriate button. The Object- 
descriptive in content (that is, describing what type of Action Manager constructs the add-on list selector 710 

input or parameters the text edit selector 620 is looking by using the combination of a selection list selector 720 

for) or it may be left blank. Additionally, the label field and an input region 730. The selection list selector 720 

622 may be a push button which, if pressed, displays is essentially the same as the selection list selector dis- 

another dialog interface screen listing valid choices for 30 cussed above in conjunction with FIG. 6. The applica- 

the text edit selector 620. When the user selects an item tions developer can restrict which actions are valid 

and presses **OK," the Object- Action Manager places within the add-on list selector 710. For example, the 

the selected item in the input field 624. The help attri- developer may set a flag which activates only the mod- 

bute provides user guidance related to the particular ify button when it is advantageous to prohibit the user 

text edit selector and only appears either when the user 35 from adding or removing a list item, 

presses the "HELP" button. Input field specifications The add-on list selector 710 is designed so that each 

include the input format required, the width of the input time the user selects an item in the selection list selector 

field and the maximum number of characters accepted. 720, the input region 730 is automatically updated with 
Other field specifications include an initial visibility of the appropriate information. The applications devel- 

the input field attribute. This attribute is particularly 40 oper may define an initial set of list items with one or 

useful when the user must enter sensitive data, such as a more attributes to be displayed in the list. Consequently, 

password, and the contents are to be hidden. the input region 730 will correspond to these attributes 

An important feature of the text edit selector 620 is and, when the user selects an object, each associated 
the validation callback attribute. This attribute ensures item will be accordingly displayed, 
that the user has entered a proper input to the text edit 45 The input region 730 comprises a set of selectors, 
selector 620. The validation callback attribute can be These selectors may be a static text, a text edit, or a 
either a system command or a callback function that is selections list selector (see discussion above with re- 
defined by the applications developer, spect to FIG. 6). While the input region 730 is automati- 

The toggle selector 630 provides a check box which cally updated when the user selects an item from the 

can be turned on or off. The toggle selector 630 typi- 50 selection list 720, the converse is not true. After the 

cally represents state information relative to some as- input region 730 is updated, an intermediate action, such 

pect of the application. For example, a toggle selector as pressing a control button, must be taken before the 

may be used to control the on/off state of a tape drive selection list 720 is updated. 

rewind. Label field 632, help attribute (not shown) and An important feature of the Object-Action Manager 

toggle state are among the different attributes for the 55 is now discussed with respect to FIG. 8, wherein a step 

toggle selector 630. The developer may also dim the menu map is illustrated. The step menu interface 800 is 

toggle; that is, the toggle's selectability may be disen- utilized when the user must perform a complex task and 

gaged when the developer does not want the user it is advantageous to "step" the user through the task, 

changing the toggle's state. Generally, the step menu 800 is a special-purpose task 

The push button selector 640 provides a button 60 dialog interface where the only selectors used are push 

which, when selected or "pressed," initiates a specified button and static text. The step menu 800 comprises a 

action. In addition to the label field 642, help and visibil- titlebar 810, a push button control region 820, a static 

ity attributes, the push button selector has a callback text region 830, and a control area 840. The titlebar 810 

attribute that identifies the operation to be performed contains the relevant information to identify the specific 

upon pressing. This operation may be a command, func- 65 task to be performed by the step menu 800. The push 

tion or identifier of a task dialog to display. button control region 820 contains the relevant steps of 

The read-only list selector 650 presents the user with the task, one button per step. The static text region 830 

information that, except for scroll bar manipulations, may contain instructional comments for the user or it 



03/13/2004, EAST Version: 1.4.1 



5,438 

13 

may be used to display status information (for example, 
indicating what steps have already been performed). 

The applications developer may specify when the 
steps in the task take effect. That is, the step menu 800 
may be either designed so that each step must be per- 5 
formed before the state of the application is modified, or 
designed so that the state of the application is changed 
as each step is performed. In the first instance, the appli- 
cation must cache the information necessary to make 
every change when the user finally presses the OK 10 
button of the step menu 800. 



659 

14 

While the present invention has been illustrated and 
described in connection with the preferred embodi- 
ment, it is not to be limited to the particular structure 
shown. It should be understood by those skilled in the 
art that other modifications and variations may be possi- 
ble in light of the above teachings. For example, object 
lists can be represented in forms other than a table of 
textual information such as pictorial representations of 
the objects and associated attribute bar graph represen- 
tations. 



Appendix A - Description File Grammar Specification 
This appendix shows an example of an Object-Action Manager description file syntax. Words in 
bold font represent key words in the description file language. 

Basic definitions: 

"string" - arbitrary text inside double quotes 

'identifier" - same convention as C except 25 character max. case insensitive 
Tunc_name* • same conventions as C 

'number* - group of digits. > 0 (decimal system used; not Roman numerals) 
*[* - represents two or more possible choices 
Beginning of description file: 
start: 

me_first_func object_Hst_def 

me_first_func task_dialog_def 

me_first_Func step_menu_def 
me_firsi_func: (Oorl) 

execute me first func_name() /* function */ 

Object list: 

object_list_def: 

object_list_screen identifier { object_Iist_guts } 
object_Hst_guts: 

label string 

exit callback func_name() /* function "/ 

statuses 

subareas 

actions 

statuses: /* O or more V 

status_item identifier 

label string 

default string 

width number [ width * 
subareas: /* 1 or more */ 

subarea identifier { subarea_guts ) 
subarea_guts: 

label string 

help identifier 

mnemonic string 

entry callback func_name() /* function V 

table_def 

actions 
table_def : 

table { table_guts } 
table_guls: /* 1 or more V 

init func name() | init string /*function | command*/ 

attr identifier { attr guts } 

attr_guts: /• 1 or more */ 

label string 

column number 

justify left | justify right 

width number | width * 

type alpha | type numeric /* used for sorting V 

key /* used in primary key column V 

actions: /* 0 or more */ 

action identifier { action_guts } j separator 
action_guts: /* 1 or more V 

label siring 

mnemonic string 

action _spec 

action_option 
action_spec: 

do func_nameO | do string J do identifier | { action_guts } /'function | command | window 
) cascading actions*/ 

action—option: /• 1 of V 
radiobutton on | radiobutton off 
toggle on | toggle off 

gray when no selections | gray when multiple selections | gray when no or multiple 
selections 
Task Dialog: 
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-continued 

Appendix A - Description File Grammar Specification 
This appendix shows an example of an Object-Action Manager description file syntax. Words in 
bold font represent key words in the description file language. 

task_dialog_def: 

task—dialog identifier {task_dialog_guts selector_defs} 
task_dialog_guts: 

label string 

help identifier 

task_monitor always | task—monitor never | task_monitor defauli 
buttons standard | buttons read—only | buttons repeatable_ task 
ok callback func_name() | ok callback identifier /* function | command */ 
entry callback func_ name() /* function */ 
exit callback func_ name() /* function */ 
selector— defs: /*1 or more V 

static— texi identifier { static_text_ guts } 
toggle identifier { toggle— guts } 
push-button identifier { push— button_guts } 
text_edit identifier { tcxt_edit_ guts } 
selection— list identifier { selection— list— guts } 

addon_list identifier { addon_list_ guts addon_ list—input— region > 
rcad_only_list identifier { read_only_list_gULS } 
skip— line | skip— line number 
indent number 

new— column width number | new_ column width * 
group identifier { group—guts selector— defs } 
static_text_guts: 
label string 

visible true | visible false 

reset Uue | reset false 
toggle— guts: 

label string 

help identifier 

default on j default ofT 

visible true | visible false 

gray true | gray false 

reset true | reset fake 

callback func_ name() /* function */ 
push— but ton— guts: 

label string 

help identifier 

width number | width * 

visible true | visible false 

gray true | gray false 

reset true | reset false 

callback func_ name() | callback string | callback identifier /*function | command | 
window */ 

text— edit_guts; 
label string 
default string 
format string 
help identifier 
width number | width * 
maxchars number 
optional true | optional false 
visible true | visible false 
textvisible true | textvisible false 
editable true | editable false 
reset true j reset false 

column identifier /* Addon list column mapping V 
callback func_ name© | callback string /• function | command V 
choices { choices_guts } 
choices— guts: 
label string 
help identifier 

data string I string2 . . . stringN /• UI variables allowed in strings V 
selected— Items string | selected -litems number 
height number 
width number | width * 
entry callback func_name(j /* function V 
selection_list_guts: 
label string 
help identifier 

callback func_ nameO /* function */ 

height number 

width number | width * 

visible true ] visible false 

optional true j optional false 

reset true | reset false 

multiselection true | multiselection false 

data stringl string2 . . . stringN /* UI variables allowed in strings •/ 
selected—items selected— items— specs 

representation Ibtbox | representation radiobuttons | representation toggles | 
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Appendix A - Description File Grammar Specification 
This appendix shows an example of an Object-Action Manager description file syntax. Words in 
bold font represent key wards in the description file language. 

representation optionbutton' 

column identifier /* Addon list column mapping •/ 
listbox—columns 
addon_,list_guts: 
label string 
help identifier 

add callback func_name() /* function */ 

remove callback func_naine{) /* function V 

height number 

width number j width * 

visible true j visible false 

optional true | optional false 

reset true j reset false 

modify __only true j modify _on!y false 

selected_i terns selected_items_specs 

data string 1 string 2 . . , stringN /* UI variables allowed in strings */ 

listbox_columns 
addon_list_input region: 

input_region { input_region_selectors } 
input_region_selcctors-. /* I or more V 

text_cdit identifier { text_edil_guts } 

seIcction_list identifier { select ion_list_guts } /* Must be optionbutton */ 
static—text identifier { static_text_guts } 
skip_line | skip_line number 
indent number 

ne\v_co!umn width number | new_column width * 
group identifier { input_region_selectors } 
read_only„list_guts: 
label string 
help identifier 
height number 
width number | width * 
visible true | visible false 
reset true ] reset false 

data string 1 string2 . . . stringN /* UI variables allowed in strings */ 

listbox_columns 
selected __items_spccs: /* 1 or more, intermixing legal*/ 

string | number 
listbox—columns: /* 0 or more V 

attr identifier { listbox_column_guts } 
Hstbox_column_gul$: 

label string 

width number | width * 
justify left | justify right 

data string! string2 . . . stringN /* UI variables allowed in strings */ 
private 
group_guts: 
label string 

border on | border off 

reset true | reset false 

visible true | visible false 
Step Menu: 

step_menu_def: 

step_menu identifier { step_menu_guts steps } 
step_menu_guts: 

label string 

help identifier 

binding late | binding immediate 

task_monitor always | task_monitor never | task_monitor default 
prompt string 

ok callback func—nameO f ok callback identifier /* function | command */ 

entry callback func_nameO /* function */ 

exit callback func aameO /* function V 

abort callback func_nameO /* function */ 
steps: /• 2 or more */ 

step identifier { step_guts } 
step_gut$: 

label string 

help identifier 

do func_nameO | do string | do identifier /■ function j command | window V 

width number j width * 

gray true | gray false 

status—text string 

optional true | optional false 



We claim: an object-action manager for building and operating a 

1. A computer system comprising: developer-defined user interface within predeter- 
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mined parameters, the developer-defined user in- 
terface managing interaction between an end-user 
and an application created by a developer, the 
object-action manager further comprising 
parser means for reading a description file and 5 
creating data structures from the description file, 
the description file being created by the devel- 
oper using a simple definition syntax, the parser 
means creates the data structures according to a 
late binding convention; 10 
object-list builder means connected to the parser 
means for defining an object-list interface screen 
according to the predetermined parameters and 
the data structures created from the description 
file; 15 
dialog-box builder means connected to the parser 
means for defining a task dialog interface screen 
and a step menu interface screen, both according 
to the predetermined parameters and the data 
structures created from the description file; 20 
library means connected to the object-list builder 
means and the dialog-box builder means for stor- 
ing and operating access functions used during 
operation of the developer-defined user inter- 
face; and 

display handler means connected to the object-list 
builder means, the dialog-box builder means and 
the library means, the display handler means for 
displaying at least one interface screen and man- 3Q 
aging interaction between the end-user and the 
application created by the developer. 

2. The object-action manager as recited in claim 1, 
wherein the object -list interface screen comprises: 

an object-list region which displays a set of objects ^ 
and associated attributes, said object-list region 
accessible by the end-user and being scrollably 
viewable; and 

a menubar disposed above the object-list region and 
having action means and view means, both for ^ 
manipulating the set of objects and associated attri- 
butes displayed on the object-list region. 

3. The object-list interface screen as recited in claim 
2, wherein the view means, which provides the end-user 
with a capability to manipulate the display of the set of 45 
objects and associated attributes for creating a custom- 
ized view, comprises: 

an attribute columns manipulator to adjust the display 
of attributes associated with the set of objects; 

a filter to suppress at least one object so that said at 50 
least one object is not displayed; and 

a sorter to display the set of objects and associated 
attributes according to a selected criterium. 

4. The object-action manager as recited in claim 1, 
wherein the task dialog interface screen comprises: 55 

a control area having at least one pressable control 
button and being accessible by the end-user, said at 
least one pressable control button performs a pre- 
determined action when pressed; and 

a task region disposed above the control area and 60 
having at least one selector, said task region pro- 
viding a means for manipulating a selected object 
and associated attributes from the object-list inter- 
face screen upon said at least one control button 
being pressed. 65 

5. The task dialog interface screen as recited in claim 
4, wherein said at least one selector provides a means 
for accepting an input from the end-user, said input 



indicative of a manner in which to manipulate the se- 
lected object. 

6. The task dialog interface screen as recited in claim 
5, wherein said at least one selector comprises a text edit 
selector which accepts a textual string input. 

7. The task dialog interface screen as recited in claim 
5, wherein said at least one selector comprises a toggle 
selector having two opposing states switchable by the 
end-user. 

8. The task dialog interface screen as recited in claim 
5, wherein said at least one selector comprises a push 
button selector which is pressable by the end -user. 

9. The task dialog interface screen as recited in claim 
5, wherein said at least one selector comprises a selec- 
tion list selector having a means to select at least one 
item from a list of items. 

10. The task dialog interface screen as recited in claim 
5, wherein said at least one selector comprises an add-on 
list selector which provides a list of objects and a means 
for manipulating the list. 

11. The task dialog interface screen as recited in claim 
4, wherein said at least one selector provides a means 
for displaying information indicative of the selected 
object. 

12. The task dialog interface screen as recited in claim 
11, wherein said at least one selector comprises a static 
text selector for displaying information to the end-user. 

13. The task dialog interface screen as recited in claim 
11, wherein said at least one selector comprises a read- 
only selector having at least one list of objects and 
scrollable means for reviewing said at least one list of 
objects. 

14. The object-action manager as recited in claim 1, 
wherein the step menu interface screen comprises: 

a control area having at least one pressable control 
button and being accessible by the end-user, said at 
least one control button performs a predetermined 
action when pressed; 

a push button control area disposed above the control 
area and having at least push button selector press- 
able by the end-user, said at least one push button 
selector performs a predetermined task when 
pressed; and 

a static text region adjacent to the push button con- 
trol area for displaying information to the end-user. 

15. An object-action manager for creating and manip- 
ulating a high-level user interface for managing interac- 
tion between an end-user and a developer-defined appli- 
cation, comprising: 

a parser for reading a description file and creating 
data structures for building user interface screens, 
said description file having screen definitions for 
user interface screens, said parser creates said data 
structures according to a late binding convention; 

an object-list builder connected to the parser which 
receives the data structures from the parser, said 
object-list builder creates an object-list interface 
screen according to the data structures, the object- 
list interface screen having an object-list region and 
a menubar disposed above the object-list region, 
the object-list region displays a set of objects and 
associated attributes, said object-list region accessi- 
ble by the end-user and being scrollably viewable, 
the menubar having view means for manipulating 
the set of objects and associated attributes dis- 
played on the object-list region to create a custom- 
ized view; 
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a dialog-box builder connected to the parser which 
receives the data structures from the parser, said 
dialog-box builder creates a task dialog interface 
screen and a step menu interface screen both ac- 
cording to the data structures, the task dialog inter- 5 
face screen having a first control area and a task 
region disposed above the first control area, the 
first control area having at least one pressable first 
control button accessible by the end-user, said at 
least one pressable first control button performs a 10 
predetermined action when pressed, the task region 
having at least one selector and a means for manip- 
ulating a selected object and associated attributes 
from the object-list interface screen, the step menu 
interface screen having a second control area with ] 5 



22 

at least one pressable second control button acces- 
sible by the end-user, said at least one pressable 
second control button performs a predetermined 
action when pressed; 

a library of access functions connected to the object- 
list builder and the dialog-box builder, said library 
having at least one subroutine for manipulating the 
end-user interface; and 

a display handler connected to the object-list builder, 
the dialog-box builder and the library of access 
functions, said display handler manages interaction 
between the end-user of the user interface and the 
object-action manager. 

* * * * * 
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